Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pip-dns-01.txt < prev next >

Wrap

Text File | 1993-07-08 | 37KB | 911 lines

Network Working Group P. Francis INTERNET-DRAFT S. Thomson Bellcore June 1993 Use of DNS with Pip Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification describes the use of DNS to support Pip. Because Pip carries IDs and addresses separately, and because Pip Addresses are variable length, DNS must be modified to support Pip. Also, Pip addresses are more likely to change than IP addresses. To enable DNS to still cache aggressively in the presence of address changes, we propose adding functionality to DNS to allow resolvers to ask for later versions of information when previously returned information is found to be out-of-date. In addition to these necessary modifications, we have chosen to add new information to DNS to support transition and to support Pip features, such as policy routing, mobile hosts and routing through Public Data Networks. Later multicast support will be added as well. Pip WG, Expires December 30, 1993 [Page 1] INTERNET-DRAFT Pip DNS June 1993 Acknowledgements The authors would like to acknowledge Bob Smart and Garrett Wollman for their initial work on Pip in DNS. Conventions All functions in this specification are mandatory. 1. INTRODUCTION Pip is an internet protocol intended as the replacement for IP ver- sion 4. Pip is a general purpose internet protocol, designed to han- dle all forseeable internet protocol requirements. This specifica- tion describes the use of DNS to support Pip. Because Pip carries IDs and addresses separately, and because Pip Addresses are variable length, DNS must be modified to support Pip. Also, Pip addresses are more likely to change than IP addresses. To enable DNS to still cache aggressively in the presence of address changes, we propose adding functionality to DNS to allow resolvers to ask for later ver- sions of information when previously returned information is found to be out-of-date. In addition to these necessary modifications, we have chosen to add new information to DNS to support transition and to support Pip features, such as policy routing, mobile hosts and routing through Public Data Networks. Later multicast support will be added as well. In spite of this additional functionality, we retain the fundamental DNS paradigm of source-independency (a resource record is returned to the requestor no matter who the requestor is). We also retain the fundamental DNS paradigm that the information stored by DNS does not change often. This document is meant to be read in conjunction with RFC 1034 and RFC 1035, and is an extension of the latter. The last draft of this document defined new resource records to support the functionality mentioned in the above paragraphs. Some of these definitions have been updated in this draft and they are motivated in more detail. In addition, we discuss not only how DNS is to be used to support the transition of hosts from using IP to using Pip, but also how DNS is to make the transition itself from storing only IP information to storing both IP and Pip information. In this draft, we also propose a Pip WG, Expires December 30, 1993 [Page 2] INTERNET-DRAFT Pip DNS June 1993 scheme for requesting later versions of resource records using what we call "timestamped queries". This draft is still rough, and subject to change and expansion. Com- ments are very welcome. 2. SUMMARY OF PIP DNS INFORMATION The fundamental information that needs to be stored in DNS to support Pip includes the following: 1. One or more Pip identifiers[1] (Pip IDs) per host. Pip identif- iers are 64 bits in length and are used to denote the source and destination in a Pip packet, typically hosts. Initially, there will be one Pip identifier per host. Ultimately, there may be several Pip identifiers per host, as they may be used to denote per-host entities such as processes rather than just the host itself. In any case, Pip identifiers name a host uniquely. At the time of writing, it is an open issue whether Pip identifiers have hierarchical structure. We assume they do have structure here, and that the structure is encoded in the identifier, that is, the Pip identifier is self-describing. 2. Multiple Pip addresses per host[3]. Pip addresses are hierarch- ical and provider-rooted. They have a provider part and a sub- scriber part, and each part may have multiple levels of hierar- chy. Typically, a host will have one private address (used by hosts within the same subscriber network) and one or more exter- nal addresses, one per provider. In Pip, we choose to use DNS to support transition, mobility, routing through Public Data Networks and policy routing[3]. The information needed is as follows: 1. The address of a Pip/IP translator positioned at the border between the Pip domain and the IP domain. This is used in com- munications between Pip and IP hosts. When the destination is an IP-only host, the Pip host must address the Pip packet to the Pip/IP translator positioned at the border between the IP domain and the Pip domain. Note that in the case where both source and destination are IP-only with Pip in the middle, the entry Pip/IP Pip WG, Expires December 30, 1993 [Page 3] INTERNET-DRAFT Pip DNS June 1993 translator must do a DNS query to obtain this information. 2. One or more Mobile Address Servers. Pip supports mobility using non-mobile hosts or routers to keep track of the location of mobile hosts. DNS is used to store the name of the mobile address server for each mobile host. In the case where a host is predominantly mobile (that is, doesn't have a "normal" reachable address), the host may have no Pip addresses stored in DNS. The host's mobile address server may be used directly to determine the current address of the host. 3. Public data network address. This indicates what the public data network address is for hosts connected via a public data network (PDN). This address can be put in an option of the Pip header, and subsequently used by the PDN entry Pip router. 4. Descriptive information associated with the backbone represented by (the provider part of) the Pip Address. The purpose of this information is to allow the source to make a policy decision. The descriptive informatation includes backbone type (e.g. internet) restriction class (e.g. commercial, research), avail- able Type of Service (TOS) (e.g. full-motion video, voice, tel- net), and provider name (ANS, AT&T, etc.). The intention of the information is that it be useful and sufficient for the large majority of users, but not necessarily satisfy every possible policy requirement. The information will allow the source to choose the best destination provider given a user or policy preference for the use of a particular source address. 3. NEW CLASS AND RESOURCE RECORD (RR) DEFINITIONS A new class is introduced to support Pip queries. The class supports all existing non IP-specific resource records in unmodified form, and replaces the definition of IP-specific records, notably the IP address record (type A), with RR types storing a Pip identifier and a Pip address. New RR types are introduced to support new information that has no counterpart in IP, such as backbone descriptors and PDN addresses. Pip WG, Expires December 30, 1993 [Page 4] INTERNET-DRAFT Pip DNS June 1993 3.1. Storing Pip Identifiers and Address Information The fundamental additions to DNS are the resource records storing Pip identifiers and addresses. An important requirement for efficiency is that the Pip identifier and addresses for a particular host be retrievable in one DNS query. Another requirement is that Pip addresses should be retrievable in one query given either a hostname or Pip identifier. (Logically, a Pip identifier can be thought of as just another name for a host.) The latter requirement means that we cannot store the Pip identifiers and addresses based on the domain name of a host, since looking up on a Pip ID would then require two queries to DNS, one to map the Pip ID to a hostname (using a PTR query), and one to map a hostname to a set of Pip addresses. Thus, we define Pip identifiers to be indexed by canonical domain name, while Pip addresses are stored per Pip identifier. These mappings have the additional advantage that communication with IP-only hosts during transition is supported transparently. (See Section 3.5). A draw- back of this approach is that if hosts are allocated multiple Pip IDs, addresses will be stored redundantly, once for each Pip ID. If this is a problem, we can introduce canonical Pip IDs and aliases as is done for host domain names. We assume for now that hosts only have one Pip ID. Thus, two resource records are needed: one to store a Pip identifier and one to store a Pip address. The IP type A RR is replaced by a resource record that stores a Pip identifier instead of an IP address. We define a Pip type A query to return the Pip ID as an answer and the Pip addresses associated with the Pip ID as additional information. The type A resource record for the Pip class has the following format (more detailed definitions of the data fields of this and other Pip RRs are given in the Appendix): <owner> <ttl> Pip A <Pip ID> The <owner> of the RR is the domain name of a host. In a RR, <Pip ID> is a 64-bit word. In the master file, a Pip identifier is represented in its textual format, which consists of eight 2-digit hex numbers separated by dots[1]. The Pip address RR for the Pip class is defined as follows: <owner> <ttl> Pip ADDR <subtype> <data> The <owner> is an inverse lookup name based on a Pip identifier. Pip WG, Expires December 30, 1993 [Page 5] INTERNET-DRAFT Pip DNS June 1993 (Inverse lookup domains are discussed in the following section.) Several types of address information can be stored in this resource record. The <subtype> field is a 16-bit integer and is used to dis- tinguish between them. The most common data field comprises a Pip address, denoted by subtype 1. Pip addresses are encoded in RRs as a sequence of 32-bit words, as described more fully in the Appendix. In the master file, a subtype is written as an integer, and the Pip address in its textual format, which is a list of numbers, separated by commas (to indicated changes in metalevel) and dots (to indicate changes in level of hierarchy or different providers in a route frag- ment)[2]. The above definitions are used to store the fundamental information: Pip identifiers and addresses. As already mentioned, we choose to use DNS to store other types of addressing information too, to support mobility and use of Public Data Networks. Moreover, we would like all address information to be returned in one query. Thus, the ADDR field has been defined to include a subtype field as shown above to enable an ADDR query to return more information than just "ordinary" Pip addresses. (If, after experimentation, this is found to be unneces- sary, the subtype field should be removed and separate resource record types used.) A subtype of 2 indicates that the data field is the Pip ID of a mobile address server for the <owner>. Type ADDR additional section processing is performed on the Pip ID of the mobile address server to yield its addresses. A mobile address server should not itself be mobile, but if the database indicates that it is, this should be ignored by the name server when answering an ADDR query (to avoid circularities). To support the storage of PDN addresses, Pip addresses are defined to cause additional section pro- cessing to yield a PDN address. PDN resource records are discussed below. 3.2. Storing Public Data Network Addresses The PDNA RR has the following form: <owner> <ttl> <class> PDNA <PDN-addr> PDNA records are stored per (subscriber part of) a Pip address. The <owner> is an inverse lookup name based on a Pip address. (Inverse lookup domains are discussed in Section 3.4). In a master file, the PDN address is written as a string of decimal digits. This record Pip WG, Expires December 30, 1993 [Page 6] INTERNET-DRAFT Pip DNS June 1993 causes no additional section processing. 3.3. Storing Backbone Information A new resource record is added to store information about a provider, called a backbone descriptor (type BBD). At the time of writing, the record is expected to contain at least the following 4 fields for each provider: the name, type, usage restriction classes and types of service available. Since it is not clear at this stage precisely what backbone information needs to be stored, we define the resource record to be extensible by making the fields self-describing. The BBD RR has the following form: <owner> <ttl> <class> BBD <mnemonic field0> <mnemonic field1> <...> BBD records are stored per (top-level component of) a Pip address. The <owner> is an inverse lookup name based on a Pip address. See below for address domains. In a RR, <mnemonic> is an 8-bit integer and <field> a <character-string>. In a master file, the BBD fields are prefixed by a mnemonic integer which indicates the type of the field that follows. The fields are character strings. This record causes no additional section processing. 3.4. PIP-ADDR.ARPA and PIP-ID.ARPA domains The two special domains, PIP-ADDR.ARPA and PIP-ID.ARPA are used to map Pip addresses and Pip identifiers to regular domain names, respectively. As with IP addresses, the PTR resource record type is used to query this mapping. The PTR query type causes no additional section processing. Pip address domain names are represented by a sequence of hex labels in reverse order with the suffix PIP-ADDR.ARPA. The labels correspond to each component of an address and are separated by dots and commas, in the same way as defined for the textual representation of Pip addresses[2]. Pip identifier domain names are represented by hex labels in reverse order, with the suffix PIP-ID.ARPA. These labels are determined from the hierarchical structure of the Pip Pip WG, Expires December 30, 1993 [Page 7] INTERNET-DRAFT Pip DNS June 1993 identifier[1]. Identifier labels are separated by dots. The PIP-ID.ARPA domain is also used to map Pip identifiers to Pip addressing information (ADDR type), while the PIP-ADDR.ARPA domain is also used to map Pip addresses to backbone descriptors (BBD type) and PDN attachment point addresses (PDNA type). 3.5. DNS Support for IP/Pip transition. NOTE: This section assumes IPAE transition. A new transition scheme is being proposed for Pip, and this will be taken account of in a later draft. We mentioned in Section 2 that we choose to use DNS to store the addresses of translating routers for IP hosts. The name service can be used to support IP/Pip host transition by assigning IP hosts spe- cial "IP-only" Pip IDs (identifiers with a well-known prefix indicat- ing the named host is IP-only, and containing the IP address in the low-order 32 bits) and using the address of the appropriate translat- ing router as their "normal" Pip address. Note that no extra RR types are needed to perform this mapping; the translator addresses are stored in place of a host's Pip addresses, transparently to DNS and the resolver. (If the name server or resolver does need to know that a host is IP for any reason, this can be determined from the special prefix of the Pip identifier given to the host.) Also, note that storing the addresses of the translator as the Pip addresses of IP hosts (rather than storing the Pip ID of the translator and having that map onto the translator addresses) does not duplicate informa- tion in the database. In Pip, the addresses used for translation are different from those used to address the translating machine as a destination host. 4. TRANSITION FROM IP NAME SERVICE TO PIP NAME SERVICE During transition, we expect that zones with a Pip host have a Pip name server. (A Pip name server is one that is authoritative for Pip information. Note that this does not necessarily mean the name server Pip WG, Expires December 30, 1993 [Page 8] INTERNET-DRAFT Pip DNS June 1993 can communicate using Pip.) However, we do not expect zones that con- tain only IP hosts to deploy a Pip name server, at least not immedi- ately. Moreover, we do not think it practical to expect other sites to maintain Pip name servers for IP sites. (As stated in the section above, servers are needed to store Pip addresses of translating routers for IP zones, but we expect that the amount of information needed for this purpose is significantly smaller than the database of each IP zone.) Thus, the Pip naming tree will not be complete for some period of time. This has a number of repercussions for resolvers. First, recursive resolvers (typically, found in name servers) must have access to both Pip and IP name servers and must be able to determine which name servers support Pip and which IP. Class infor- mation is provided in name server (NS) resource records. In order to obtain NS RRs of a particular class, however, a recursive resolver must ask parent name servers the appropriate class of query. Such information must be gleaned by trial and error. (NS resource records are not usually explicitly requested - they are returned as a by- product of a query for some other resource record to a non- authoritative server. When a Pip query is made to a non-authoritative name server, Pip NS RRs will be returned in the authoritative section of a response. When an IP query is made, IP NS RRs will be returned in the authoritative section of a response.) Note that in general an address request might require 3 queries if the host being looked up is IP-only, assuming a Pip class query is made first: failure of a Pip class query will require a separate IP class query. Since we are using DNS to store addresses of translating routers for IP hosts, another lookup is required to get the Pip address of the translating router. The efficiency of recursive resolvers can be improved in a number of ways. The fact that a zone does NOT support a certain class should be cached and timed out in the same way as name server resource records are. This prevents future queries during the time-to-live period from having to rediscover this (negative) information. Also, for IP hosts in zones with Pip name servers, the number of queries can be reduced by assigning the IP hosts special Pip identifiers (as explained in Section 3.5) and storing these Pip identifiers and the addresses of the appropriate translating router in the Pip database. Pip address queries for these hosts will succeed in one query. The fact that the Pip naming tree is not complete also affects the efficiency of operation of stub resolvers, typically found in Pip hosts. (A stub resolver relies on a name server (with a recursive Pip WG, Expires December 30, 1993 [Page 9] INTERNET-DRAFT Pip DNS June 1993 resolver) to perform resolution as it is, by definition, incapable of following referrals. It usually does not cache any information.) Stub resolvers are not as amenable to optimization as they do not in gen- eral cache name server RRs and thus do not have any information to indicate what class of query to make when looking up the address of a host. A Pip stub resolver can be assisted by having the name server it relies on to resolve queries to decide on which class of query to perform. As explained above, a name server can potentially do a much better job of determining which class of query to make, since it caches name server records and knows what classes of requests a name server supports, or at least knows how to find out in the absence of such information. Hence, it is more efficient for stub resolvers on Pip hosts to always make Pip class queries and have the name servers decide what class of query to make in the event of a referral and perform any translation necessary to return a valid Pip response. When the name server is referred to a Pip name server, no translation is required. When the name server is referred to an IP-only name server, the query must be translated into an IP query. On receiving a response from the IP name server, the query must be translated back to that of the original class, and the resource records formatted to appear as valid Pip records. In particular, all IP addresses must be translated to appear as Pip identifiers with their associated Pip addresses. To achieve this, the IP hosts are given special Pip iden- tifiers (based on their IP addresses). These identifiers are then looked up separately to retrieve the corresponding Pip addresses for the IP hosts. The addresses are the addresses of the IP hosts' translating routers. 5. TIMESTAMPED QUERIES In Pip, hosts are able to tell when the address of a destination host is out-of-date. This will typically happen when a destination changes provider (its address prefix will change). A host is able to tell that the destination address has changed since, in Pip, the provider's routers are configured to return a PCMP Packet Not Delivered Message for an address with an old prefix for some period of time after the change occurs[4]. To enable DNS to still allow high enough time-to-live values for efficient operation, but yet still maintain connectivity with hosts whose addresses have changed, we propose that DNS be enhanced to allow a resolver to ask for later versions of resource records than it currently has cached. Pip WG, Expires December 30, 1993 [Page 10] INTERNET-DRAFT Pip DNS June 1993 The proposed scheme involves assigning version numbers to resource records, which are incremented whenever the information is changed. In a query, a resolver specifies the version number of the RRs requested, and the name server responds with RRs that have version numbers greater than that specified. If the name server does not have the data locally or has an old version, it must refer the request to name servers "closer" to the answer in the normal way. If the name server is authoritative for RRs requested, it always answers the question independent of the version number requested. The version numbers could be timestamps, in which case they may have additional semantic significance, e.g. they may indicate when the RR was added to the database or the last time the RR was modified. Alternatively, they could be sequence numbers similar to zone serial numbers. Other proposed extensions to DNS also require RR version information, such as incremental zone transfers mentioned recently on the namedroppers mailing list. This scheme requires that version information be comparable with zone serial numbers. If both times- tamped queries and incremental zone transfers are to be added to DNS, then it would make sense to use a common definition. Whatever the form of version numbers chosen, there must be a way for a requestor to ask for any version of a RR, that is, the first version found. Such a query would be used by a resolver when requesting a resource record for the first time. 5.1. Changes to Message Format According to RFC 1035, there are three sets of queries that can be made to DNS, standard queries, inverse queries and status queries. When a query is made, a field in the header, called the operation code, indicates what kind of query it is. To enable timestamped queries, a new version of the standard query is proposed. The following new operation code is thus defined: Op Code Value and Meaning ------- ----------------- QUERY2 4 Timestamped queries The format of messages will need to change to support timestamped queries. The header will remain the same to maintain backwards Pip WG, Expires December 30, 1993 [Page 11] INTERNET-DRAFT Pip DNS June 1993 compatibility, but the new operation code will indicate that the for- mat of the question section and the definitions of RRs have been extended. The current definition of the question section consist of three fields: the name of the domain being queried, the type of the query (typically a RR type) and the class of the query (typically Inter- net). An extra field will be added to include the version informa- tion. The precise form of this field is not yet defined, but it will likely be a 32-bit field. The question section has the following for- mat (original from RFC 1035): +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | VERSION | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: QNAME <domain-name> QTYPE A 16-bit field specifying the type of the query QCLASS A 16-bit field specifying the class of the query VERSION A 32-bit field specifying that the answer must be a later version than that specified. A version number of zero is used to indicate that a version number is not known or that a resource record with any version number is requested. RRs will also be extended to include the version information field. Currently, RRs consists of the name of the domain the record describes, the type of the record, its class, the time-to-live field, which indi- cates how long the RR can be cached, as well as the data and its length. A 32-bit version field could follow the TTL field as follows (original RR format from RFC 1035): Pip WG, Expires December 30, 1993 [Page 12] INTERNET-DRAFT Pip DNS June 1993 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | VERSION | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME A <domain-name> to which this RR pertains QTYPE A 16-bit field specifying the type of the RR. This field specifies the meaning of the data in the RDATA field. QCLASS A 16-bit field specifying the class of the data TTL A 32-bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. VERSION A 32-bit field specifying the version number of the data in the RDATA field. RDLENGTH An unsigned 16-bit integer specifying the length of the octets of the RDATA field. RDATA A variable-length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. 6. APPENDIX The Pip class is chosen to have value 5. The following types of resource records are added to DNS (or redefined) to store Pip infor- mation. The type A and ADDR resource records are Pip-specific. The Pip WG, Expires December 30, 1993 [Page 13] INTERNET-DRAFT Pip DNS June 1993 other resource records can be used by any class. Type Value and Meaning ---- ----------------- A 0 Redefined to store Pip identifier ADDR 64 Different types of address information, such as Pip addresses and names of mobile address servers BBD 65 Backbone descriptor PDNA 66 PDN attachment point address 6.1. New Resource Record (RR) data definitions Below we define the data fields for each of the new Pip resource records. Some data fields are defined in terms of <domain-name>s and <character-string>s. These two field types have the same definitions as stated in RFC 1035. We also define an <octet-string>, which is similar to a <character-string>, but consists of a string of unsigned 8-bit fields only. Two other new fields include the Pip identifier and the Pip address. A <pip-identifier> is a 64-bit field containing a Pip ID represented in its modified ASN.1 notation[1]. A <pip- address> consists of a sequence of 16-bit numbers called FTIFs (For- warding Table Index Fields), each representing a level of the hierar- chy, or a provider in a route fragment. A Pip address is represented in a RR by a sequence of 32-bit words, each containing an FTIF, and the metalevel, if appropriate, as shown below: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / ML | reserved | FTIF / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ML An 8-bit field containing the metalevel of this FTIF. This field is only set in the first FTIF of each metalevel (zero otherwise). <reserved> An 8-bit field reserved for later use. Should be zero. FTIF A 16-bit field containing the FTIF value. Pip WG, Expires December 30, 1993 [Page 14] INTERNET-DRAFT Pip DNS June 1993 The data format for Pip identifiers (type A), addresses (type ADDR), backbone descriptors (type BBD) and PDN addresses (type PDNA) follow: A data format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PIPID | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PIPID A <pip-identifier> associated with the specified <domain-name> Type A RRs cause type ADDR additional section processing. ADDR data format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | reserved | subtype | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / data / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: <reserved> A 16-bit field reserved for later use. Should be zero. <subtype> A 16-bit integer indicating the type of data to be found in the data field. <data> In the case of subtype 1, a <pip-address> of the specified owner. In the case of subtype 2, the <pip-identifier> of the mobile address server for the specified owner. ADDR queries do cause additional section processing. In the case of subtype 1, PDNA queries are performed on Pip addresses. In the case of subtype 2, ADDR queries are performed on Pip identifiers. Note that an ADDR query will not be performed again as part of additional section processing if the mobile server itself has a Pip WG, Expires December 30, 1993 [Page 15] INTERNET-DRAFT Pip DNS June 1993 mobile address server. BBD data format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MNEMONIC | BBDFIELD / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MNEMONIC An 8-bit field indicating the type of information contained in BBDFIELD. BBDFIELD A <character-string> that contains information of the corresponding type. Standard values for mnemonics must still be defined. This record causes no additional section processing. PDNA data format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / PDNADDR / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PDNADDR An <octet-string> that specifies the public data network attachment point address in encoded form as a sequence of 4-bit digits. This record causes no additional section processing. References [1] Francis, "Pip Identifiers", Internet-Draft [2] Francis, "Pip Address Conventions", Internet-Draft [3] Francis, "Pip Near-term Architecture", Internet-Draft [4] Francis, "Pip Host Operation", Internet-Draft Pip WG, Expires December 30, 1993 [Page 16]